Internet Tools (InfoMagic)/Internet Tools.iso/dos_win/winsock/hacklist/94-04.Z/94-04/[e-mail]_Fri Apr 1 23:36:33 1994.msg

Internet Message Format | 1994-04-30 | 6KB

Received: from onpmomma.isc-br.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA09918; Sat, 2 Apr 1994 10:37:41 -0500
Received: by onpmomma.isc-br.com (Smail3.1.28.1 #3)
    id m0pn7kP-000A9lC; Sat, 2 Apr 94 07:36 PST
Message-Id: <[e-mail]>
Subject: Re: What does send() returning 0 mean ? revisited
To: [e-mail]
Date: Sat, 2 Apr 94 7:36:33 PST
From: Carl Paukstis <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>; from "Bob Quinn" at Apr 1, 94 8:32 pm
X-Mailer: ELM [version 2.3 PL11]

Bob Quinn writes:
>
>Since there is no obvious reason to reject a length of zero (it's
>not a useful request, but it's not a harmful one), we return 0.

>should not fail without good reason.  Since there are unforeseen
>conditions under which an application can sometimes mistakenly
>try to send 0 bytes, there's no reason for the DLL to punish
>them for it.

<APPLAUSE>

Right answer, Bob!

--
Carl Paukstis, RRR&RSG   DoD#0432 1KQSPI=8.80   [e-mail]
Olivetti North America                          [e-mail]
(Oli North): will deny responsibility    voice: [phone] 0700-1600 M-F
Spokane, Washington, USA                   FAX: [phone] hrs.
From [e-mail] Tue Apr  5 11:18:55 1994
Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA29470; Tue, 5 Apr 1994 02:05:55 -0400
Received: by usage.csd.unsw.OZ.AU id AA13525
  (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Tue, 5 Apr 1994 16:05:58 +1000
Received: by atlas (4.1/1.35)
    id AA09083; Tue, 5 Apr 94 16:18:56 EST
Message-Id: <9404050618.AA09083@atlas>
From: [e-mail]
Date: Tue, 5 Apr 1994 16:18:55 -0500
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: [e-mail],
        Multiple recipients of list <[e-mail]>
Subject: Re: Winsock on top of DOS stacks.

Thus expounded Alun Jones on Apr 1,10:50pm:
/--------------------
|If Windows exits unexpectedly, and yet the DOS subsystem is still
|running, and if the underlying TCP/IP stack is a DOS-based system (and
|still running), should all connected/listening sockets be closed?
|Under at least one implementation, for instance, when going back into
|windows, my ftp daemon won't start, because (it claims) the ftp port
|is being listened on by some other process (presumably my previous
|instance under windows).

I would have thought the DLL, if at all possible, should keep track of
sockets owned by a given application, and clean them up if the
application exits. A DLL has a routine called when the DLL
itself is unloaded (i.e. when the last application using WINSOCK exits)
which can be used to perform this cleanup. Of course, if
Windows crashes out so this routine is never called, then the DOS
subsystem has no way of knowing there is no longer an application
to own the sockets. And if there was a socket with a WSAAsyncSelect active,
in all likelyhood the next callback will crash DOS as well.

If by 'exist unexpectedly' you mean Windows crashing out to the DOS prompt
without exiting cleanly, then it would be unlikely that the DOS
system will cleanly close the sockets for you. If Windows exits cleanly,
then yes, the DLL should close all outstanding sockets before it
exits.


--
Paul Brooks              |[e-mail]       |Emerging Standard:
TurboSoft Pty Ltd        |[e-mail]|  one that has not yet
579 Harris St., Ultimo   |                         |  been superseded.
Sydney Australia 2007    |ph: [phone]       |
From [e-mail] Tue Apr  5 06:20:43 1994
Received: from post.demon.co.uk by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA21145; Tue, 5 Apr 1994 06:20:43 -0400
Received: from gateway.alex.com by post.demon.co.uk id aa05038;
          5 Apr 94 11:17 GMT-60:00
Return-Path: <[e-mail]>
Received: from SKID by woody.alex.com (4.1/SMI-4.1)
    id AA28610; Tue, 5 Apr 94 11:01:27 BST
Date: Tue, 5 Apr 94 11:01:27 BST
Message-Id: <[e-mail]>
X-Sender: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: [e-mail]
From: Bryan Boreham <[e-mail]>
Subject: Re: Closing and reusing sockets
X-Mailer: <PC Eudora Version 1.4>

> From: [e-mail]

> [loads of stuff -- should one call bind?]

> Now, the twist from your last sentence (above) is that you want to
> bind() and connect() from a free reserved port - only in this case is
>                             ---- ======== ----
> it necessary or recommended to call bind() before connect().

Thanks for this confirmation.

> To avoid WSAEADDRINUSE errors, you must make sure a socket is fully closed
> before you can connect _from_the_same_port_number_ to the same remote
> machine listening on the _same_remote_port_ - possibly by blocking in
> a lingering close, or using linger to hard-close the connection when
> you're done the first time.

This is roughly what I said in the very first message in this thread --
hard-closing
the socket makes the problem go away.  I guess that waiting for the close to
complete (probably not actually blocking, given that we're all nice cooperative
Windows programmers) is gentler, but it would complicate the exit logic of the
program rather a lot.

This would all be a lot easier if we could rely on bind() giving EADDRINUSE
so that the next port could be used instead, and leave the stack to
get on with closing down the old one quietly.

Bryan.